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METHODS AND APPARATUS FOR MODIFYING 
PROGRAMS STORED IN READ ONLY MEMORY 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates to embedded systems. More 
particularly, the invention relates to methods and apparatus for 
modifying embedded system programs stored in read only memory 
(ROM) . 

2. State of the Art 

Digital computing systems are typically known to include 
hardware and software. Software is typically stored on a writable 
medium such as a magnetic disk. As most computer users know, 
software often contains errors or mistakes which prevent it from 
functioning properly. Software vendors often publish updates or 
"patches" to correct errors in software. An update is typically a 
new complete version of the original software which is intended to 
replace the entire original program. The original software is 
erased from the writable medium and the replacement software is 
written to the writable medium in place of the original. A patch 
is a program which is run to modify the original software. The 
patch program finds the portion (s) of the software which need to 
be replaced and overwrites them with replacement code. 
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1 Today, digital computing systems are ubiquitous and often 

2 unseen. These systems are designed to perform specialized 

3 functions such as controlling the operation of an appliance, a 

4 motor vehicle, or a computer peripheral device such as a modem or 

5 a printer. Such computing systems are usually referred to as 

6 "embedded systems". They include a microprocessor and software 

7 which is typically stored on a read only memory (ROM) . ROM is 

8 advantageous because it is non-volatile, small, inexpensive, and 
jjjj 9 energy efficient. Program code stored on ROM is usually called 
-jl 0 "firmware" rather than software because once it is stored on ROM, 
^jl 1 the code cannot be modified. The code takes on the quality of 
Ul2 hardware in the sense that in order to change it, the physical ROM 
=*13 device must be replaced. Indeed, many embedded systems have 

d 4 "socketed" ROM so that the ROM can be easily unplugged and 

Hi 

|j|5 replaced with a new ROM if the program needs to be changed, 

j J 6 However, that is not always practical or convenient. 
17 

1 8 One known method for alteration of firmware programs in ROM- 

19 based systems is disclosed in U.S. Patent Number 4,607,332, issued 

20 on August 19, 1986 to Goldberg. The method allows for dynamic 

21 alteration of ROM programs with the aid of random access memory 

22 (RAM) and through the use of the standard linkages associated with 

23 subroutine calls in the system processor. When each ROM-based 

24 routine is written, one program statement is a call to a ROM- 

25 located processing routine which searches a RAM--located data 
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1 structure. If there exists a correspondence between information 

2 passed on the call to the processing routine and certain elements 

3 of the data structure, a RAM-based program is substituted for the 

4 ROM-based program. After adjusting the processor to the states 

5 just after the call to the ROM-based program, the processing 

6 routine effects a transfer to the replacement routine in RAM. The 

7 location of this replacement routine is also found in the data 

8 structure. The main disadvantage of the method proposed by 

9 Goldberg is that it is inefficient. It uses up too much space in 
;|0 ROM and RAM. It also requires an external compiler/ interpreter . 
;| 1 Since the processing function is ROM-based, it is limited in scope 

and potential to be modified. The ROM-based function also 

il 3 presents excessive processing overhead since it must perform a 

C|4 search for possible replacement code even when no replacement code 

fit 5 exists 
3 6 

1 7 Another system for altering ROM-based firmware is disclosed 

18 in U.S. Patent Number 5,740,351, issued on April 14, 1998 to 

19 Kasten. The system relies on an "extensible interpreter", i.e. a 

20 modified FORTH kernel and a plurality of customizable call outs 

21 (CCOs) . CCOs are present in the ROM-based program. When a CCO is 

22 encountered during execution of the program, the modified FORTH 

23 kernel takes control and looks for the called function or 

24 parameter. If it is found (in RAM or in ROM), it is executed or 

25 fetched and the result is returned by the modified FORTH kernel to 
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1 the next instruction in the ROM program. The system is primarily 

2 intended for interactive use with a dumb terminal during 

3 "debugging" of the ROM-based program. CCOs in RAM must be defined 

4 using the modified FORTH kernel. The main advantage of Kasten 

5 over Goldberg is that Kasten does not require an external 

6 compiler /interpreter. Disadvantages of Kasten are that it is 

7 limited to modifications made using the FORTH programming language 

8 and it is inefficient, requiring that a substantial part of ROM be 
^ 9 devoted to the modified FORTH kernel. 

mo 

1 Still another system for altering software in embedded 

CJ2 systems is disclosed in U.S. Patent Number 5,901,225, issued on 

«13 May 4, 1999 to Ireton et al. The system includes an embedded 

(=1 4 system device coupled to an external memory. The device includes 

\j] 5 a non-alterable memory, including firmware, coupled to a 

H6 processor. The device further includes a relatively small amount 

17 of patch RAM within the device also coupled to the processor. 

18 Patches are loaded from the external memory into the patch RAM. 

1 9 The device further includes a means for determining if one or more 

20 patches are to be applied. If the device detects a patch to be 

21 applied, the system loads the patch from the external memory into 

22 the patch RAM. The device also includes a breakpoint register. 

23 When the value of the program counter of the processor equals the 

24 value in the breakpoint register, a patch insertion occurs, i.e., 

25 the processor deviates from executing firmware to executing patch 
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1 instructions. The system described by Ireton et al . is quite 

2 complex. 
3 

4 SUMMARY OF THE INVENTION 

5 

6 It is therefore an object of the invention to provide methods 

7 and apparatus for modifying firmware code stored in a read only 

8 memory. 



h 

^ 0 It is also an object of the invention to provide methods and 

4* 

S1 1 apparatus for modifying firmware code stored in a read only memory 

y a 

CJ 2 which make efficient use of RAM. 

i 3 

e: 

Scss " 

j;J 4 xt is another object of the invention to provide methods and 

Hi 

Q 5 apparatus for modifying firmware code stored in a read only memory 

H6 which are relatively simple in architecture. 

pa 

17 

18 It is also an object of the invention to provide methods and 

1 9 apparatus for modifying firmware code stored in a read only memory 

20 which do not require any decision making elements in ROM to 

21 support future code modifications. 
22 

23 It is another object of the invention to provide methods and 

24 apparatus for modifying firmware code stored in a read only memory 
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1 which do not require any processor specific or processor dependent 

2 elements . 
3 

4 It is still another object of the invention to provide 

5 methods and apparatus for modifying firmware code stored in a read 

6 only memory which are applicable to any programming language. 
7 

8 It is also an object of the invention to provide methods and 

H 9 apparatus for modifying firmware code stored in a read only memory 

Clio which do not limit the scope of future code modifications. 
MM 

Ui 

y 12 xt is another object of the invention to provide methods and 

3i l3 apparatus for modifying firmware code stored in a read only memory 

l~j4 which incur minimum processing overhead. 

Pis 

ui 

jll 6 xt is still another object of the invention to provide 

1 7 methods and apparatus for modifying firmware code stored in a read 

1 8 only memory which minimize the size of ROM code segments needed to 

19 be replaced to fix an error. 
20 

21 In accord with these objects which will be discussed in 

22 detail below, the apparatus of the invention includes an embedded 

23 device having program code stored in ROM and an on-board or 

24 external RAM for storing modified code, segments . The methods of 

25 the invention include structuring the ROM-based firmware so that a 
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1 RAM-based function is called prior to each potentially modifiable 

2 code segment. Prior to modifying the firmware, a dummy function 

3 is stored in RAM so that every call to RAM is simply returned to 

4 ROM. When a segment of code is to be modified, a replacement is 

5 stored in RAM and indexed by the return address of the function 

6 call. The system of the present invention is efficient as it uses 

7 very little RAM. It does not require any ROM-based decision 

8 making elements; and it is not limited to a particular programming 

9 language or processor. The system of the invention is most 
suitable for use in a computer peripheral which communicates with 

11 a higher level controller, e.g. a personal computer, from which, 

pi 2 replacement code can be downloaded. Alternatively, replacement 

ill 

r 13 code in RAM can be loaded by a small bootstrap program (i.e. a 

{=! 4 run-time system initialization program) stored in replaceable 

"1 c 

y] 5 external ROM. 

s 

1 7 Additional objects and advantages of the invention will 

18 become apparent to those skilled in the art upon reference to the 

1 9 detailed description taken in conjunction with the provided 
2 0 figures . 

21 

22 BRIEF DESCRIPTION OF THE DRAWINGS 
23 

24 Figure 1 is a simplified block diagram of an embedded system 

25 according to the invention; 
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Figure 2 is a schematic illustration of the organization of 
ROM-based code according to the invention; 

Figure 3 is a schematic illustration of the dummy function in 
RAM according to the invention; 

Figure 4 is a schematic illustration of the replacement code 
in RAM indexed to return address; and 

Figure 5 is a simplified flowchart of the operation of the 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring now to Figure 1, an embedded system 10 according to 
the invention includes a processor 12 which is coupled to a 
firmware ROM 14 and a RAM 16. As illustrated in Figure 1, the RAM 
16 is ideally much smaller than the ROM 14, for example 
approximately one one hundredth the size of the ROM. 

Turning now to Figure 2, according to the invention, the 
firmware stored in the ROM 14 is divided into code segments, e.g. 
18a-18d, 20a-20d, 22a-22d, and 24a-24d. Prior to the start of 
each code segment, a call function with a (calling and) return 
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1 address is placed, e.g. at 18, 20, 22, and 24. The locations of 

2 the call functions are preferably organized for the most efficient 

3 use of RAM. It might seem practical to locate each call function 

4 at each logical break in the code, e.g. at the start of each new 

5 routine. However, in the case of very long routines, it can be 

6 more efficient to place call functions equally spaced throughout 

7 the routine. This will be better understood after considering the 

8 code listings below. Essentially, whenever replacement code is 

H9 used, all of the code from the call function until the corrected 

1=1 

C|0 code is reached is replaced. Thus if there are one thousand lines 

s 4 1 of code between call functions and only the six hundredth line of 

lit _ 

Cf 2 that code needs to be changed, six hundred lines will be replaced 

'<■'£} 

~1 3 nonetheless. If the call functions were spaced every one hundred 

j=]4 lines throughout the thousand line routine, no more than one 

jj|5 hundred lines would need to be replaced. Thus, a balance must be 

j~t6 struck between the number of call functions placed throughout the 

1 7 ROM-based code and the amount of RAM needed to make code 

1 8 replacements . 

19 

20 Figure 3 illustrates the structure of RAM 16 when none of the 

21 code segments in ROM is to be replaced. A dummy function 26, 

22 including instruction lines 26a-26d resides in RAM 16. Whenever a 

23 call function (18, 20, 22, 24 in Figure 2) is executed, the dummy 

24 function 26 responds by returning program execution to the return 
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address (which is usually the next line after the calling function) . 

Figure 4 illustrates the structure of RAM 16 when some of the 
code segments in ROM are to be replaced. In this case, the Return 
in the Dummy Function is replaced with a branch to the 
corresponding Patch Center Function. According to the presently 
preferred embodiment, a lookup table 28, including a "patch center 
function" (line 1 of the RAM table) provides the functionality 
necessary to determine whether a code segment has a replacement in 
RAM. Operation of the patch center function is described in more 
detail below with reference to Figure 5 and Code Listing 2. The 
lookup table is illustrated schematically at lines 2-4 of the RAM 
table, line 2 being the start of table (SOT) and line 4 being the 
end of table (EOT) . Each entry in the lookup table refers to a 
return address (RA) and a patch address (PA) . For example, the 
first entry refers to a return address of X+l and a patch address 
of 5. This signifies that the code being replaced is a 
replacement (shown at 30 in Figure 4) for code segment X; the 
replacement code begins at line 5 in the RAM table and upon 
execution of the replacement code, execution continues at an 
address specified in the replacement code, typically the next 
segment after X. It is possible to replace only a portion of a 
code segment and return to a line within the original code segment 
to continue execution. As will be seen below in Code Listing 2, 
it is necessary to replace a contiguous set of code lines from the 
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call function forward. Similar entries are indicated for code 
segment Y and Z replacements which are illustrated at 32 and 34 in 
Figure 4. 

Referring now to Figure 5, when the patch center function is 
called at 100, the lookup table entries are scanned at 102. If a 
return address match is found at 104, program execution is 
directed to the patch address at 106. The replacement code is 
executed at 108, and program execution is returned to a ROM 
address specified in the patch code at 110. So long as the end of 
the table has not been reached as determined at 112, the patch 
center function looks for a table entry for replacement code. 
When it is determined that the end of the table has been reached, 
program execution returns to the return address in ROM at 114. As 
mentioned above, if there is no replacement code in RAM, program 
execution returns to the return address specified by the call 
function which also acts as an index to the lookup table. If 
replacement code is executed, the return address is specified by 
the replacement code. 

The operation of the invention will be better understood with 
reference to the following Code Listing 1 and Code Listing 2 which 
illustrate the structure of the code in ROM and RAM respectively. 
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1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
1 1 
12 
13 
14 
15 
16 
17 

5.1 8 

□ 9 
|| 0 

422 
23 

L24 
-25 
"126 
±1 
;28 
1=29 
(30 

ffi 
:33 

534 
^35 
36 
37 
38 

39 

40 

41 

42 

43 

44 



******************************* 

* Code Listing 1 (ROM Segment) 
******************************* 

Code_in Rom: 

Patch_Calll() 



Patch_Calll() 



; Function call 



Patch_Call2(] 
R0M_Return__Addr2 : 

I = I + 10 

K + K - 55 
ROM_Address2 : 

M = M + 88 



Patch_Call2 () 
J = J - 15 



Return Address (RA) 
Segment code starts 
Need modification ! 



; segment code ends 



Patch_Call2 () 



Patch_Call3 () 



Patch_Call3 () 



Code Listing 1 (ROM fiprmmanl-) 

Referring to Code Listing 1, a code segment is shown with 
seven patch calls at lines 7, 11, 15, 23, 27, 31, and 35. Most of 
the code is not shown but is represented by dots, i.e. at lines 8- 
10, 12-14, 21, 22, 25, 26, 28-30, and 32-34. The code which will 
be modified follows patch call2() at line 15. 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
1 1 
12 
13 
14 
15 
16 
17 
U 8 
i*19 
!=20 
5 :21 
4 22 

23 

IJ24 
i:25 

% 

: ! 28 

29 
?h30 
1B1 
IB 2 
?33 
C34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 

48 

49 

50 



******************************* 

* Code Listing 2 (RAM Segment) 
******************************* 

Code_in_RAM: 

Patch_Calll 

Return 

Patch_Call2: 

Go to Patch_Center 2 

Patch_Call3: 

Return 



Patch_Center2 : 

Save_Context ( ) 



; Dummy function 

; Return to ROM Code 

; Dummy Function 

; Replace Return here ! 

; Dummy Function 

; Return to ROM Code 



; Patch Center Function 
; Save necessary registers 



Address_Match = Patch_Address_Table_Search ( ) 

; Lookup table searching 

if (Address_Match == YES) 
Go to Patch_Code2 

else 

Res tore_Con text ( ) 
Return 



Patch_Center2_Lookup_SOT : 
R0M_Re t urn_Addr 2 
Patch_Code2 



Pa tch_Center_Lookup_EOT : 

Patch_Code2 : 

I = I + 10 

K = K - 99 

Res tore_Con text ( ) 

Return to R0M_Address2 



Have replacement code 

Restore the registers 
Return to ROM code 

Start of Lookup Table 
Return Address (RA) 
Patch Address (PA) 



End of Lookup Table 

Patch Address (PA) 
Replacement code 
Replace K = K - 55 in ROM 
Restore the registers 



Code Listing 2 (RAM Segment) 

Turning now to Code Listing 2, lines 6-13 represent the dummy 
functions. As shown, patch calls 1 and 3 are dummy functions 
which return the program to ROM. Patch call 2 directs the program 
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to patch center 2 which begins at line 18. Patch center 2 saves 
the context and checks the address match. The address match 
lookup table is illustrated at lines 31-37. If the address 
matches, the program is directed to patch code 2 which starts at 
line 39. If the address does not match, context is restored and 
the program is returned to ROM. As shown at lines 39-43, patch 
code 2 is designed to replace two lines of code in code listing 1, 
i.e. replace lines 17 and 18 of code listing 1 with lines 34 and 
35 of code listing 2. After executing lines 40 and 41 of code 
listing 2, context is restored at line 42 and the program is 
returned to ROM at 43. The return address is indicated in code 
listings 1 and 2 as ROM_Address2 . The actual return address is 
derived from knowledge of the code in ROM. It should be noted 
that line 40 of code listing 2 is identical to line 17 of code 
listing 1. Nevertheless, it is replaced because, as mentioned 
above, the function calls according to the invention allow and 
require replacement of all code from the function call through the 
corrected code. 

There have been described and illustrated herein methods and 
apparatus for modifying program code stored in ROM. While 
particular embodiments of the invention have been described, it is 
not intended that the invention be limited thereto, as it is 
intended that the invention be as broad in scope as the art will 
allow and that the specification be read likewise. It will 
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therefore be appreciated by those skilled in the art that yet 
other modifications could be made to the provided invention 
without deviating from its spirit and scope as so claimed. 
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